Approving. Verified at 8bd9edf: cargo metadata --locked is clean, and the merged state equals this head, so that check covers the merge result. Injected a manifest/lock mismatch to confirm the gate is real: clippy --locked fails with "cannot update the lock file ... because --locked was passed", and passes again once reverted. Patch bump is right, no feat or breaking-change commits in v0.7.0..HEAD. The Cargo.lock hunk is exactly the five workspace version lines with no dependency drift, which is the lock-sync job doing its job on its first release.

Three notes, none blocking:

Findings

• [P3] Deduplicate two changelog entries in a follow-up. CHANGELOG.md:6-9, :17-18. 99b2b9a/a49e04d and 1964f88/e2560ee repeat the same subject. This is new in 0.7.1; the 0.7.0 section has none. Every PR in the range landed as a two-parent merge commit and the queue's merge method is MERGE, so the merge commit's body repeats a branch commit's fix: subject and both get counted. The lever is the merge method, not release-please config, and I have not tested that switching it fixes this.
• [P3] Add the missing icaptcha-client entry, or accept the omission knowingly. 9be5eac is in the range with no changelog line, while every other branch-level fix: commit has one. It arrived on #213, whose merge commit body is a test: line. gl depends on that crate by path, so the change ships in 0.7.1 unlisted.
• [P3] Add crates/icaptcha-client/Cargo.toml to extra-files, or drop its annotation. release-please-config.json:10-16 lists five crates; crates/icaptcha-client/Cargo.toml:3 carries # x-release-please-version and sits at 0.4.0 while the rest moved to 0.7.1. Cargo.toml:15-17 claims every annotated crate is listed under extra-files, which is not true for this one. Pre-existing since #138, and it needs its own PR since hand edits here get regenerated.